home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / modula2 / 135 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.7 KB
  1. Path: fourier.newcastle.edu.au!peter
  2. From: peter@fourier.newcastle.edu.au (Peter Moylan)
  3. Newsgroups: comp.lang.modula2
  4. Subject: Re: Modula2 for C programmers?
  5. Date: 23 Jan 1996 04:28:47 GMT
  6. Organization: The University of Newcastle
  7. Message-ID: <4e1o5v$6i8@seagoon.newcastle.edu.au>
  8. References: <erico-1801961940460001@infinitehell.cnmat.berkeley.edu>
  9. Reply-To: peter@tesla.newcastle.edu.au
  10. NNTP-Posting-Host: fourier.newcastle.edu.au
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Eric Obermuhlner (erico@cnmat.berkeley.edu) wrote:
  14.  
  15. >How do I do the ugly things that C programmers like so very much in Modula 2?
  16. >Like getting a pointer to a var, pointer arithmetic, bit operations (shift, and, or, exor).
  17.  
  18. All of these things are possible (but see below).
  19. (a) p := ADR(v) makes p point to v;
  20. (b) Pointer arithmetic: support varies from one compiler to another,
  21.     but in the libraries you'll likely find procedures like
  22.     SYSTEM.AddOffset and the like.  Early versions of Modula-2
  23.     even allowed arithmetic on variables of type ADDRESS, but
  24.     this mistake has since been corrected.
  25. (c) Bit operations: usually supported in some low-level library
  26.     module.  If not, you can fake them by type-casting to
  27.     BITSET, though this is a messy solution.
  28.  
  29. The obvious question, though, is why you would want to do this.
  30. Such operations are common in C programming because C lacks
  31. more elegant ways to get the job done.  In Modula-2, there are
  32. certainly situations where you want to do weird hardware-dependent
  33. things and break the type system, but those situations should
  34. arise only when writing very low-level modules.  In most other
  35. cases, there's almost always a better way to do the job.
  36.  
  37. Why, then, do C programmers like the ugly style so much?
  38. I can think of two main reasons:
  39.  1. For whatever reason, C does not support the concept of an
  40.     "array".  (The syntax makes it look as if arrays are
  41.     supported, but when you dig deeper you discover that it's
  42.     just a shortcut notation for certain pointer operations.)
  43.     Thus C programmers get used to the idea of doing things
  44.     like stepping a pointer through an array, even when it
  45.     would be easier and clearer - and often more efficient -
  46.     to use subscripts.
  47.  2. Student programmers are often misled into thinking that
  48.     low-level programming leads to greater efficiency.
  49.     (Especially when they've graduated from using Basic to
  50.     C; there's no doubt that C is faster than Basic, but then
  51.     anything's faster than Basic.)  Often they're wrong, but
  52.     they're so convinced that this conclusion is "intuitively
  53.     obvious" that they simply refuse to make the comparison.
  54.  
  55. --
  56. Peter Moylan                       peter@ee.newcastle.edu.au
  57.                            ftp://ee.newcastle.edu.au/pub/www/Moylan.html
  58.